今日目標

經過前幾天的開發與測試，智慧醫院管理平台第一階段「醫院預約網站」的主要功能已經完成。

從最初使用 Figma 設計 UI，到將畫面實作成 HTML、CSS，再逐步轉換為 Angular Component，後續也加入 ASP.NET Core Web API 與 Oracle Database，讓原本只有前端畫面的網站，逐漸成為可以實際查詢醫師、登入會員及建立預約的系統。

在 Day 29 完成完整系統整合測試後，今天主要將已完成的功能與開發成果整理成作品集，並準備網站展示所需的畫面、操作流程及技術文件。

這次不以開發新功能為主，而是從整體系統的角度，重新檢視第一階段的功能、技術架構、完成程度與後續可以改善的地方。

今日規劃

• 整理第一階段已完成的頁面與功能。
• 回顧從 Figma 到 Angular 的前端開發過程。
• 整理 ASP.NET Core 與 Oracle 的系統架構。
• 規劃完整的網站操作展示流程。
• 整理正式功能與 Demo 功能的差異。
• 彙整自動化測試與真實 Oracle 整合測試成果。
• 規劃網站截圖與操作展示影片。
• 整理目前尚未完整驗收的功能與後續開發方向。

一、第一階段開發成果回顧

1. 從 Figma 開始進行 UI 設計

專案最初先使用 Figma 規劃醫院預約網站的操作流程與頁面。

在進入程式開發前，我先思考一般使用者會如何使用醫院網站，例如：

• 如何查詢醫師？
• 如何查看醫師的門診資訊？
• 如何進行預約掛號？
• 登入後要如何查看自己的預約紀錄？
• 使用手機時，是否能順利完成操作？

接著逐步完成首頁、醫院介紹、醫師查詢、醫師詳細、會員登入、預約掛號、預約成功、我的預約、個人資料及就醫資訊等頁面的 UI 設計。

除了單一畫面，也使用 Figma Prototype 串接頁面，模擬使用者的操作流程。

透過這個階段，我了解到網站設計不只是把畫面做出來，也需要考慮使用者進入每個頁面的方式，以及操作完成後應該導向哪裡。

Figma Prototype 頁面

https://www.figma.com/proto/amHPOOuZXVL8IvtbaLER2N/%E6%99%BA%E6%85%A7%E9%86%AB%E9%99%A2%E7%B3%BB%E7%B5%B1?node-id=131-68&starting-point-node-id=131%3A68&t=mRA5ud1rf0x9W8go-1

2. 從 HTML、CSS 轉換成 Angular

完成 Figma 設計後，我一開始先使用 HTML 與 CSS 練習將畫面實作成網頁。

最初完成的部分包括：

• Header 與導覽列。
• Hero 主視覺區域。
• 快速服務卡片。
• 醫師搜尋區塊。
• Footer。
• 各頁面的基本排版。

實作過程中，主要使用 Flexbox、CSS Grid、Media Query、Hover 等方式調整畫面。

後來考量網站會有多個頁面，而且不同頁面會重複使用 Header、Footer、醫師搜尋等區塊，因此開始將原本的 HTML、CSS 逐步轉換為 Angular Component。

例如：

Header Component
Hero Component
Quick Service Component
Doctor Search Component
Footer Component

透過 Component 的方式，可以讓相同的介面在不同頁面重複使用，也比較方便後續維護。

另外，也使用 Angular Router 管理多個頁面，讓網站不再只是獨立的 HTML 檔案，而是具有完整導覽結構的前端專案。

Angular 網站首頁

二、系統技術架構

第一階段採用前後端分離架構，主要分為 Angular 前端、ASP.NET Core Web API 與 Oracle Database 三個部分。

1. 前端：Angular

前端主要負責：

• 顯示網站介面。
• 接收使用者輸入。
• 處理頁面導覽。
• 執行基本表單驗證。
• 呼叫後端 API。
• 顯示醫師、會員及預約資料。

使用技術包括：

2. 後端：ASP.NET Core Web API

後端主要負責接收 Angular 發送的請求，處理登入驗證、業務邏輯與資料庫存取。

例如：

• 會員註冊與登入。
• 取得目前登入會員。
• 醫師資料查詢。
• 日期化診次查詢。
• 建立預約。
• 查詢及取消預約。
• 個人資料查詢與更新。

後端使用 C# 與 ASP.NET Core .NET 9，並依照專案實際設計將程式拆分為 Controller、Service、Repository 與 DTO 等部分。

另外，會員登入使用 Cookie Authentication，修改資料的請求也加入 CSRF 保護。

3. 資料庫：Oracle 19c

Oracle 主要儲存系統需要的正式資料，例如：

• 使用者帳號。
• 病人資料。
• 醫師資訊。
• 正式門診診次。
• 預約掛號紀錄。

以前端預約功能為例，當使用者選擇正式診次並確認預約時，Angular 會將指定資料送給 Web API。

後端確認會員身分、診次狀態及剩餘名額後，再處理 Oracle 資料庫交易。

完成後，前端可以透過 API 重新取得預約詳細資料。

4. 系統架構圖

flowchart TD
    A["使用者瀏覽器"] --> B["Angular 前端"]
    B -->|"HTTP API"| C["ASP.NET Core Web API"]
    C --> D["業務邏輯與資料驗證"]
    D --> E[("Oracle 19c Database")]
    E --> D
    D --> C
    C -->|"JSON 回應"| B
    B --> A

這次整理技術架構後，我對前後端分離的概念更加清楚。

Angular 不會直接連接 Oracle，而是由後端 API 負責處理資料存取及驗證，前端只需要依照 API 契約傳送請求並顯示回傳結果。

系統架構圖

https://www.figma.com/proto/amHPOOuZXVL8IvtbaLER2N/%E6%99%BA%E6%85%A7%E9%86%AB%E9%99%A2%E7%B3%BB%E7%B5%B1?node-id=131-68&starting-point-node-id=131%3A68&t=mRA5ud1rf0x9W8go-1

三、Oracle 資料庫設計與整合

除了前端畫面與後端 API，這次專案也使用 Oracle 19c 儲存會員、醫師及預約掛號等資料。

在開發初期，網站主要使用固定的 Demo 資料顯示畫面，後續開始建立正式的資料庫結構，並透過 ASP.NET Core Web API 將資料提供給 Angular。

1. 主要資料表

目前第一階段主要使用以下資料表：

這次透過不同資料表的關聯，讓會員可以查詢醫師、選擇診次，以及查看自己的預約紀錄。

2. 資料表關聯

主要資料關係可以簡化為：

flowchart TD
    USERS["USERS 使用者"]
    PATIENTS["PATIENTS 病人"]
    DOCTORS["DOCTORS 醫師"]
    SCHEDULES["DOCTOR_SCHEDULES 門診診次"]
    APPOINTMENTS["APPOINTMENTS 預約紀錄"]

    USERS -->|"會員與病人關聯"| PATIENTS
    DOCTORS -->|"一位醫師可有多個診次"| SCHEDULES
    PATIENTS -->|"一位病人可有多筆預約"| APPOINTMENTS
    SCHEDULES -->|"一個診次可對應多筆預約"| APPOINTMENTS

這張圖呈現資料表的主要業務關係，方便理解系統如何將會員、醫師、診次及預約紀錄串接起來。

3. Oracle 與前後端整合

以預約掛號為例，使用者在 Angular 選擇醫師及診次後，前端會向 ASP.NET Core Web API 發送請求。

後端會確認登入會員的身分、診次是否開放，以及剩餘名額是否足夠，再透過 Oracle Transaction 處理預約資料。

完成後，使用者可以從預約成功頁、我的預約及預約詳細頁重新取得 Oracle 中的正式資料。

因此，前端不需要直接連接 Oracle，而是透過後端 API 完成資料存取。

4. 實際 Oracle 資料驗證

在 Day 29 的整合測試中，我使用虛構會員建立一筆正式預約，並透過 Oracle SELECT 查詢，確認資料確實成功寫入。

本次新增的預約資料：

建立前後的資料比對：

這次也確認原本兩筆已取消的預約紀錄沒有被修改，而新增的預約能從 Angular 的正式預約結果頁與我的預約頁重新查詢。

Oracle 資料庫關聯圖

四、第一階段核心功能展示

這次重新整理目前已經完成的功能，並依照使用者實際操作網站的順序規劃展示。

1. 首頁

首頁是使用者進入網站後最先看到的畫面。

主要包含：

• Header 導覽列。
• Hero 主視覺。
• 快速服務入口。
• 醫師搜尋區塊。
• 最新公告展示區塊。
• Footer。

首頁著重於讓使用者快速了解網站提供的服務，以及找到需要的功能。

其中，首頁搜尋目前仍保留既有 Demo 行為；正式醫師資料查詢則使用獨立的 /doctors 頁面。

網站首頁

2. 醫師查詢與醫師詳細資訊

正式醫師查詢頁透過 API 取得醫師資料。

使用者可以查看醫師資訊，進一步進入醫師詳細頁。

正式醫師詳細頁包含醫師介紹及相關門診資訊，也提供「立即預約」按鈕，讓使用者進入正式掛號流程。

主要路由：

/doctors
/doctors/1

透過這個功能，我將原本只顯示 Demo 醫師資料的頁面，逐步與 Oracle 正式醫師資料整合。

正式醫師查詢頁

正式醫師詳細頁

3. 會員註冊與登入

使用者可以透過會員註冊功能建立帳號，並使用登入功能進入需要會員身分的頁面。

這次使用 Cookie Authentication 管理登入狀態。

當使用者尚未登入，卻直接開啟需要驗證的正式預約頁面時，系統會引導使用者先登入。

登入完成後，再返回原本準備進入的頁面，減少使用者重新操作的步驟。

正式系統也包含登出及身分驗證相關處理。

會員登入頁面

會員登入註冊頁

4. 正式預約掛號

正式預約掛號是這次第一階段最重要的核心功能之一。

使用者可以選擇指定日期，查詢該醫師的正式診次。

畫面會依照 API 回傳的資料顯示：

• 門診日期。
• 門診時段。
• 診間。
• 剩餘名額。
• 是否可以預約。

系統不會將已過期、未開放或無法預約的診次當作正常可選取項目。

確認預約時，也會進行表單驗證、CSRF 驗證及提交狀態控制，避免重複送出請求。

正式路由：

/reserve/1

正式預約掛號頁面

5. 正式預約成功頁

當正式預約建立成功後，系統會使用後端回傳的預約 ID 查詢詳細資料。

這次不再使用固定 Demo 預約編號，而是顯示 Oracle 中的正式預約紀錄。

結果頁包含：

• 預約編號。
• 醫師姓名。
• 科別。
• 預約日期及時段。
• 診間。
• 預約狀態。

即使使用者重新整理頁面，也可以再次透過 GET API 取得預約資料，不需要重新送出建立預約的請求。

在 Day 29 測試中，我已使用虛構會員成功建立一筆預約，並確認 Oracle 中存在相同資料。

這次成果展示則直接使用既有預約進行唯讀查詢，不再建立新預約。

展示路由：

/reservation-success/4

正式預約成功頁面

6. 我的預約與預約詳細

登入會員可以從「我的預約」查看自己的預約紀錄。

目前頁面可以顯示不同預約狀態，包括已預約及已取消。

使用者也可以點擊單筆預約，進入詳細頁面查看醫師、日期、預約編號與狀態等資訊。

正式路由：

/appointments
/appointments/4

這次展示使用 Day 29 已完成的虛構測試資料：

• 預約 ID 4：已預約。
• 預約 ID 3：已取消。
• 預約 ID 2：已取消。

取消預約功能已有前後端實作及相關測試，但 Angular 取消 Dialog 的完整真實瀏覽器操作仍列為尚待補充驗收的部分。

因此，成果展示只查看既有紀錄，不進行取消操作。

我的預約列表

7. 個人資料

會員登入後，可以進入個人資料頁，查看會員及聯絡資訊。

這次也在個人資料卡片中加入「查看我的預約」按鈕，讓使用者能直接前往預約列表。

個人資料頁保留原本的編輯功能，以及已完成的 UI 設計。

正式路由：

/profile

目前 Profile API 及前端編輯介面已實作，相關 Mock 測試也已通過；但真實 Oracle 更新流程的完整驗收證據仍需要補齊。

此外，最新 Profile UI 在 375px、390px 手機寬度下的最終視覺檢查，也列入後續驗收。

個人資料頁

四、完整預約操作流程展示

這次我將第一階段的主要功能整理成一條完整操作流程，方便未來使用影片、截圖或現場展示專案。

flowchart TD
    A["首頁"] --> B["正式醫師查詢"]
    B --> C["醫師詳細"]
    C --> D{"是否已登入"}
    D -->|"否"| E["會員登入"]
    E --> F["正式預約掛號"]
    D -->|"是"| F
    F --> G["選擇日期與診次"]
    G --> H["確認預約"]
    H --> I["預約成功"]
    I --> J["我的預約"]
    J --> K["預約詳細"]
    J --> L["個人資料"]

這是系統完整功能的操作流程。

不過，為了避免在成果展示時重複建立 Oracle 預約，我另外規劃了安全的展示方式：

首頁
  ↓
正式醫師查詢
  ↓
醫師詳細
  ↓
會員登入
  ↓
正式預約掛號頁
  ↓
展示日期、診次與剩餘名額
  ↓
開啟既有預約成功頁
  ↓
我的預約
  ↓
預約詳細
  ↓
個人資料

展示過程只進行查詢與頁面切換，不再次送出掛號，也不取消或修改既有資料。

這樣既能介紹完整的操作流程，也能保留 Day 29 已經完成的測試證據。

網站操作流程展示影片或

https://youtu.be/YMo9vVreOfU?si=Px2cV4B-_6ZrO75t

五、Day 29 系統整合測試成果

除了展示網站畫面，這次也將先前的測試成果整理到 README，讓讀者了解系統不是只有靜態介面。

1. Angular 自動化測試

Day 29 完成整合後，Angular 測試結果為：

Mock axe 測試未完整涵蓋實際瀏覽器色彩對比，因此這部分仍與人工畫面驗收分開記錄。

Day 30 本次主要進行文件整理，沒有重新執行上述應用程式測試，所列結果沿用 Day 29 的實際紀錄。

Angular 測試結果

2. 真實 Oracle 掛號測試

在 Day 29，我使用虛構會員 syy001，透過 Angular 網站完成一次正式掛號。

建立後透過 Oracle SELECT 確認：

新增預約資訊：

另外也確認原本 ID 2、3 的取消紀錄沒有被更動。

這次測試證明，Angular 前端建立的預約能經由 ASP.NET Core Web API 寫入 Oracle，並且可以從正式預約成功頁、我的預約列表及詳細頁重新取得資料。

不過，建立當下沒有保存 POST 的 HTTP 狀態碼，因此不將 HTTP 201 列為已驗證結果。

Oracle 預約資料查詢結果

六、RWD 與畫面設計整理

在第一階段前端開發中，我也持續調整網站的 RWD。

主要使用：

• Flexbox。
• CSS Grid。
• Media Query。
• 相對寬度與最大寬度。
• 卡片及按鈕間距調整。
• 手機版欄位堆疊。

例如，桌面版的醫師卡片可以使用多欄排列，而手機版則依照螢幕寬度調整為較少欄位。

另外，也需要確認表單、導覽列與按鈕在小螢幕上不會超出畫面。

目前大部分前端頁面已有 RWD 設計，但最新個人資料頁的手機版仍需要補上實際 375px、390px 的截圖與確認。

桌面版與手機版 RWD 對照

https://www.figma.com/proto/amHPOOuZXVL8IvtbaLER2N/%E6%99%BA%E6%85%A7%E9%86%AB%E9%99%A2%E7%B3%BB%E7%B5%B1?node-id=131-68&starting-point-node-id=131%3A68&t=mRA5ud1rf0x9W8go-1

八、目前已知限制與後續改善

雖然第一階段的主要預約流程已完成，但仍有一些尚未完成或需要進一步驗收的部分。

1. 尚待補充的驗收

• 個人資料修改後，Oracle 實際更新的完整驗收證據。
• Angular 取消預約 Dialog 的完整真實瀏覽器操作。
• 最新 Profile UI 在 375px、390px 的手機版視覺檢查。

2. 尚未開發的功能

• 正式環境部署。
• 醫師端管理功能。
• 管理人員後台。
• 密碼重設。
• 預約通知。
• 實際看診進度管理。

另外，首頁部分搜尋功能仍使用 Demo 資料，與正式醫師查詢頁不同。

這些限制已經整理到 README，讓作品集可以如實呈現目前的完成程度，不將未開發的功能寫成已完成。

九、今天完成

• 完成第一階段功能盤點。
• 整理 Angular、ASP.NET Core 與 Oracle 系統架構。
• 製作 README 使用的 Mermaid 架構圖。
• 整理核心功能與正式操作流程。
• 區分正式 API 功能、Demo 功能與尚待驗收項目。
• 彙整 Day 29 的 422／422 Angular 測試成果。
• 彙整 Oracle 真實預約 ID 4 的整合測試紀錄。
• 規劃網站截圖與操作影片。
• 整理已知限制與未來開發方向。

本次主要修改的是 README 與 Day 30 相關 Markdown 文件，沒有修改 Angular、ASP.NET Core 或 Oracle 資料。

十、未來規劃

經過這 30 天的開發紀錄，智慧醫院管理平台第一階段已經完成從 UI 設計、前端實作，到後端 API 與 Oracle 整合的主要功能。

下一步希望先完成專案作品集整理，包括：

1. 補上真實網站截圖。
2. 製作簡短的網站操作影片。
3. 完成 GitHub README 的圖片整合與預覽。
4. 補充尚未完成的真實操作驗收。
5. 評估未來部署方式。
6. 進一步改善 UI、RWD 及錯誤提示。

後續若要讓其他人直接操作網站，還需要考慮前後端部署、資料庫環境、測試帳號及資料安全等問題，因此目前先以 GitHub 原始碼、截圖及操作影片作為主要展示方式。

這次最大的收穫是，我不只完成了單一頁面或 API，而是從 Figma 開始，逐步學習 Angular 元件化、前後端分離、會員驗證、Oracle 資料庫操作及系統整合測試，最後將這些成果整理成一個完整的專案作品集。